home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1298.txt < prev    next >
Text File  |  1997-04-01  |  8KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         R. Wormley
  8. Request for Comments: 1298                                    S. Bostock
  9.                                                             Novell, Inc.
  10.                                                            February 1992
  11.  
  12.  
  13.                              SNMP over IPX
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Abstract
  22.  
  23.    This memo defines a convention for encapsulating Simple Network
  24.    Management Protocol (SNMP) [1] packets over the transport mechanism
  25.    provided via the Internetwork Packet Exchange (IPX) protocol [2].
  26.  
  27. Editor's Note
  28.  
  29.    As stated below and in reference [5], it is strongly advised that for
  30.    interoperability, SNMP be implemented over UDP/IP and not directly on
  31.    media or other protocols (such as IPX).
  32.  
  33. 1.  Introduction
  34.  
  35.    The SNMP protocol has been specified as the official network
  36.    management protocol of the Internet.  Its widespread acceptance and
  37.    implementation by developers, both inside and outside the Internet
  38.    community, is fostering synergetic growth to a variety of protocols
  39.    and platforms.
  40.  
  41.    This memo addresses the use of SNMP over the IPX protocol, which has
  42.    become quite widespread principally due to the popularity of Novell
  43.    NetWare.  Roughly equivalent to UDP in function, IPX provides
  44.    connectionless, unacknowledged datagram service over a variety of
  45.    physical media and protocols.
  46.  
  47.    Although modifications have been made elsewhere in the NetWare
  48.    protocol suite, IPX is identical to the Xerox Internet Datagram
  49.    Protocol (IDP) [3].  The socket address space authority is
  50.    administered by Novell.
  51.  
  52.    The use of SNMP over the UDP transport [4] is today the common mode
  53.    of operation in the Internet. This specification may be appropriate
  54.    for some environments in which UDP transport services are not
  55.  
  56.  
  57.  
  58. Wormley & Bostock                                               [Page 1]
  59.  
  60. RFC 1298                     SNMP over IPX                 February 1992
  61.  
  62.  
  63.    available.  SNMP implementors should be aware that the choice of
  64.    underlying transport may have a significant impact on the
  65.    interoperability and ubiquity of the management capability in the
  66.    Internet.  Considerations relevant to choosing a transport for use
  67.    with SNMP are described in [5].
  68.  
  69. 2.  Specification
  70.  
  71.    SNMP packets will always set the Packet Type field in the IPX header
  72.    to 4 (i.e., Packet Exchange Packet).
  73.  
  74. 2.1  Socket Assignments
  75.  
  76.    SNMP protocol entities will receive GetRequest-PDU, GetNextRequest-
  77.    PDU, and SetRequest-PDU messages on socket 36879 (Destination Socket
  78.    field set to hexadecimal 900F), and Trap-PDU messages on socket 36880
  79.    (Destination Socket field set to hexadecimal 9010).
  80.  
  81.    GetResponse-PDU messages will be addressed to the IPX address and
  82.    socket from which the corresponding GetRequest-PDU, GetNextRequest-
  83.    PDU, or SetRequest-PDU originated.
  84.  
  85. 2.2  Maximum Packet Length
  86.  
  87.    Although SNMP does not require conformant implementations to accept
  88.    messages whose length exceed 484 bytes, it is recommended that
  89.    implementations support a maximum SNMP message size of 546 bytes (the
  90.    maximum size allowed under IPX).  Furthermore, this limit is the
  91.    maximum packet length guaranteed to traverse IPX routers which do not
  92.    provide fragmentation.  Implementors may choose to use longer packet
  93.    lengths if the maximum is known, which depends on the intermediate
  94.    routers and/or intermediate datalink layer protocols.
  95.  
  96. 2.3  The agent-addr Field for the Trap-PDU
  97.  
  98.    The agent-addr field in a Trap-PDU emitted by an SNMP agent should
  99.    contain the IpAddress 0.0.0.0.  An SNMP manager may ascertain the
  100.    source of the trap by querying the transport layer.
  101.  
  102. 2.4  IPX Transport Address Representation
  103.  
  104.    There are occasions when it is necessary to represent a transport
  105.    service address in a MIB.  For instance, the SNMP party MIB [6] uses
  106.    an OBJECT IDENTIFIER to define the transport domain (IP, IPX, etc.)
  107.    and an OCTET STRING to represent an address within that domain.  The
  108.    following definitions are provided for use in such a scheme.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Wormley & Bostock                                               [Page 2]
  115.  
  116. RFC 1298                     SNMP over IPX                 February 1992
  117.  
  118.  
  119.  RFC1298-MIB DEFINITIONS ::= BEGIN
  120.  
  121.     IMPORTS
  122.       enterprises         FROM RFC1155-SMI;
  123.  
  124.       novell              OBJECT IDENTIFIER ::= { enterprises 23 }
  125.       transportDomains    OBJECT IDENTIFIER ::= { novell 7 }
  126.  
  127.       ipxTransportDomain  OBJECT IDENTIFIER ::= { transportDomains 1 }
  128.  
  129.     -- Authoritatively names the IPX Transport Domain
  130.  
  131.     IpxTransportAddress ::= OCTET STRING (SIZE (12))
  132.  
  133.     -- A textual convention denoting a transport service address in
  134.     -- the ipxTransportDomain.  An IpxTransportAddress is 12 octets
  135.     -- long and comprises 3 fields, each in network-byte (high-low)
  136.     -- order.
  137.  
  138.     -- The first field is 4 octets long and contains the network
  139.     -- number.
  140.  
  141.     -- The next field is 6 octets long and contains the physical
  142.     -- address of the node.  Since IPX can run over a variety of
  143.     -- subnet architectures, the physical node address may not
  144.     -- require all 6 octets.  As specified in [2], the physical
  145.     -- node address will occupy the least significant portion of
  146.     -- the field and the most significant octets should be set
  147.     -- to zero.
  148.  
  149.     -- The last field is 2 octets long and contains the socket
  150.     -- number.
  151.  
  152.  END
  153.  
  154. 3.  Document Procurement
  155.  
  156.    This section provides contact points for procurement of selected
  157.    documents.
  158.  
  159.    A complete description of IPX may be secured at the following
  160.    address:
  161.  
  162.        Novell, Inc.
  163.        122 East 1700 South
  164.        P. O. Box 5900
  165.        Provo, Utah 84601 USA
  166.        800 526 5463
  167.  
  168.  
  169.  
  170. Wormley & Bostock                                               [Page 3]
  171.  
  172. RFC 1298                     SNMP over IPX                 February 1992
  173.  
  174.  
  175.        Novell Part # 883-000780-001
  176.  
  177.    The specification for IDP (part of XNS) may be ordered from:
  178.  
  179.        Xerox System Institute
  180.        475 Oakmead Parkway
  181.        Sunnyvale, CA 94086
  182.        Attn: Fonda Pallone
  183.        (415) 813-7164
  184.  
  185. 4.  References
  186.  
  187.    [1] Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple
  188.        Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
  189.        Performance Systems International, Performance Systems
  190.        International, and MIT Laboratory for Computer Science, May 1990.
  191.  
  192.    [2] Novell, Inc., "NetWare System Technical Interface Overview", June
  193.        1989.
  194.  
  195.    [3] Xerox System Integration Standard, "Internet Transport
  196.        Protocols", XSIS 028112, Xerox Corporation, December 1981.
  197.  
  198.    [4] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
  199.        Sciences Institute, 28 August 1980.
  200.  
  201.    [5] Kastenholz, F., "SNMP Communications Services," RFC 1270,
  202.        Clearpoint Research Corporation, October 1991.
  203.  
  204.    [6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
  205.        Objects for Administration of SNMP Parties", RFC in preparation.
  206.  
  207. 5.  Security Considerations
  208.  
  209.    Security issues are not discussed in this memo.
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Wormley & Bostock                                               [Page 4]
  227.  
  228. RFC 1298                     SNMP over IPX                 February 1992
  229.  
  230.  
  231. 6.  Authors' Addresses
  232.  
  233.    Raymond Brett Wormley
  234.    Novell, Inc.
  235.    2180 Fortune Drive
  236.    Mail Stop F5-91-2
  237.    San Jose, CA 95131
  238.  
  239.    Phone: 408 473 8208
  240.    EMail: bwormley@novell.com
  241.  
  242.  
  243.    Steve Bostock
  244.    Novell, Inc.
  245.    2180 Fortune Drive
  246.    Mail Stop F5-91-2
  247.    San Jose, CA 95131
  248.  
  249.    Phone: 408 473 8203
  250.    EMail: steveb@novell.com
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Wormley & Bostock                                               [Page 5]
  283.